home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc / Developer Documentation / Human Interface / Human Interface Q & A / HI Q&A #9 < prev   
Encoding:
Text File  |  1996-04-26  |  8.6 KB  |  189 lines  |  [ttro/ttxt]
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17. Q&A #9
  18. Keyboard Equivalents, Quit, Splash Screens, Buttons, and Embedded ScrollBar
  19.  
  20. By the Apple Computer OpenDoc Human Interface Team
  21.  
  22. As published in the December 1995 Apple Directions
  23.  
  24. We frequently receive OpenDoc questions that we need to answer in a public
  25. forum to help our partners' OpenDoc development efforts. We think you'd like
  26. to know about the OpenDoc topics these questions address.
  27.  
  28. Q: I received the Developer Release 3 CD and now I'm seriously writing some
  29. parts. Where do I find guidance on the human interface?
  30.  
  31. A: There are a couple of places to look for human interface information.
  32. First, Part 3 of the OpenDoc Programmer's Guide (on the DR3 CD) contains
  33. human interface guidelines for OpenDoc.
  34.  
  35. Finally, you can subscribe to the two-way OpenDoc-HI list server and send us
  36. your questions and comments. To subscribe, send a message to
  37. Listproc@cilabs.org and include "subscribe OpenDoc-HI <your name, not e-mail
  38. address>" in the body of the message.
  39.  
  40. Q: What are the guidelines for the use of keyboard equivalents?
  41.  
  42. A: Keyboard equivalents, or Command-key combinations, execute from the
  43. rightmost menu positions to the leftmost. Suppose you assign a new keyboard
  44. equivalent, and another command already has that same Command-key
  45. assignment. When the user invokes a keyboard equivalent that is assigned to
  46. more than one command, the command that will be invoked is the one that
  47. appears farthest to the right in the menu structure. The user should not
  48. have to think about which command will be invoked; duplicates make the
  49. effect of the command unpredictable and confusing to users. Users may also
  50. find it very confusing if one keyboard equivalent invokes one command in one
  51. part of the document but invokes a different command elsewhere.
  52.  
  53. We've been careful to establish keyboard equivalents that represent the most
  54. effective use of a limited resource. To minimize the potential confusion, we
  55. recommend that you use only the reserved keyboard equivalents, defined in
  56. the Human Interface Guidelines (pages 128-29), plus the OpenDoc-specific
  57. reserved keyboard equivalents L (Info) and R (Redo). You should carefully
  58. consider the alternatives before adding a new keyboard equivalent to your
  59. editor.
  60.  
  61. Q: Can we consider restoring the Quit command so that users won't be
  62. confused by today's model?
  63.  
  64. A: There are two reasons why OpenDoc does not have a Quit command. First,
  65. Quit is an artifact of an application-centered model. Because we
  66. restructured the way applications (that is, editors) are started and stopped
  67. automatically, this command is no longer necessary.
  68.  
  69. Second, we know that users often forget to use the Quit command, which can
  70. lead to disorientation. That is, when users close the last document in an
  71. application, they're left with the menu bar for that application, but they
  72. often believe they're in another domain--usually the Finder. This causes a
  73. lot of frustration for users.
  74.  
  75. It's true that issuing a Quit command also means that all open windows of
  76. the application are closed. That's sometimes a very useful feature,
  77. particularly for experienced users. One option for closing all the windows
  78. of the current document is a Close All command--which is somewhat different
  79. from Quit, but is consistent with a document-centered model. However, the
  80. Document menu is already crowded. So instead of providing a Close All
  81. command, OpenDoc 1.0 allows you to perform the same action by using
  82. Option-click on the close box or pressing Command-Option-W. (One way that an
  83. OpenDoc document might have multiple windows open is if the user were
  84. viewing a contained part in its own window, using the "View in Window" menu
  85. item.)
  86.  
  87. We know that some developers are interested in using OpenDoc technology, but
  88. aren't using the OpenDoc document model. If you are clearly working with an
  89. application model, it is appropriate to retain the Quit command. If you're
  90. considering doing this, please feel free to contact us for advice. Watch
  91. this space for further information on various content-model-specific
  92. guidelines and appropriate variations on OpenDoc guidelines.
  93.  
  94. Q: When should I display my splash screen?
  95.  
  96. A: The human interface guidelines covers this topic to some degree. While we
  97. can't give you any legal advice, we can tell you what we think is the best
  98. human interface for splash screens.
  99.  
  100. Startup is a natural time to display your part editor's name and other
  101. information in a splash screen. However, OpenDoc may start up and shut down
  102. your part editor several times during the use of a document. Therefore,
  103. displaying your splash screen each time your part editor starts up can
  104. become overwhelming to users, especially when several part editors that are
  105. used in a single document try to display their splash screens.
  106.  
  107. We prefer that splash screens appear either at the end of the installation
  108. of your editor, or upon first use. After that, the splash screen information
  109. should be made available through the "About [editor name]" command in the
  110. Apple menu.
  111.  
  112. Here are some ways to make your splash screen pleasant and unobtrusive:
  113.  
  114.   • Display your splash screen in a modeless dialog box.
  115.    
  116.   • Make your splash screen as small as possible.
  117.   
  118.   • Display your splash screen for as short a time as possible; 5 seconds
  119.      is appropriate.
  120.    
  121.   • Make your splash screen disappear automatically, without requiring user
  122.      interaction.
  123.    
  124.   • Avoid the use of buttons on your splash screen.
  125.  
  126. Q: How do I edit a button or similiar "hot" parts? Can I activate them?
  127.  
  128. A: In OpenDoc, you cannot activate a hot part. (A hot part--a button part,
  129. for example--does not activate when you click it or drop an icon on it.
  130. Instead, it takes such user events and performs some action as a result.)
  131. You can select it using whatever mechanisms the container provides, such as
  132. Shift-click, but you can't activate it. Thus, if the user needs to set
  133. properties, we recommend that the user edit the hot part's properties by
  134. selecting the part, invoking the Part Info command from the Edit menu, and
  135. clicking the Settings button. This will open the properties for this part
  136. and allow the user to edit them. Remember that as the part developer, you
  137. are responsible for adding the Settings button to your part's Part Info
  138. dialog box.
  139.  
  140. Q: The sample code I've looked at seems to finesse the whole issue of scroll
  141. bars in embedded parts by allowing scroll bars only in the root frame. (I
  142. presume there can be only one root frame per part.) Is this cheating, or is
  143. it an OpenDoc human interface guideline? When is it appropriate to use
  144. scroll bars in the frame?
  145.  
  146. A: When your part is the root part in a document window, your part editor
  147. decides whether to display window scroll bars. In general, documents should
  148. have scroll bars when they can contain more information than is visible in
  149. the window. However, some documents are WYSIWYG, and some are not. If your
  150. part is WYSIWYG, then you should probably not display the scroll bars when
  151. it is embedded, since this can cause the layout of the document to change
  152. and create visual clutter.
  153.  
  154. Some parts have a legitimate need to use scroll bars to navigate through
  155. content that is not visible in the frame. For example, a part that presents
  156. a dynamic list may need a scroll bar. On the other hand, a simple text part
  157. probably doesn't need one, since the frame could grow as a user adds more
  158. text. When you determine that it is beneficial to implement scroll bars in
  159. your embedded parts, observe the following guidelines:
  160.  
  161.    • Whenever the document window in which your part is displayed becomes
  162.      active, enable scroll bars in all of your parts that have them--even if
  163.      your part is not currently active. This allows the user immediate
  164.      access to all such parts.
  165.   
  166.    • When the user clicks in an enabled scroll bar, immediately begin to
  167.      scroll. In addition, the part containing the scroll bar should become
  168.      the active part except when the clicked scroll bar belongs to the root
  169.      part. This exception allows the user to scroll through the document to
  170.      bring obscured portions of an active embedded part into view without
  171.      losing the active state.
  172.    
  173.    • Provide a command that allows users to hide the scroll bars when they
  174.      wish. Alternatively, you could provide an editor preference for this
  175.      purpose.
  176.    
  177.    • Don't hide the scroll bars when your part becomes inactive. Rather,
  178.      show the inactive appearance of scroll bars.
  179.    
  180.    • Scrolling keys (such as the page up and page down keys) scroll the root
  181.      part. If the root part does not scroll, these keys apply to the active
  182.      part.
  183.  
  184. See the Macintosh Human Interface Guidelines for more complete information
  185. on scroll bars.
  186.  
  187. __________________________________________________________
  188.  
  189. Copyright (c) 1995 by Apple Computer, Inc. All Rights Reserved.